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abstract 


This thesis describes the design and implementation 
of a Time Sharing Operating System for the TDC-316 Computer. 

The operating system is designed as a hierarchy of 
layers. Kernel , the innermost layer,, provides the processor 
allocation and memory management for a fixed number of 
processes. The next layer contains the device subsystems, 
which provide logical services from the devices. This layer 
also contains the Error*>trap handlers and various system 
processes. The top layer consists of the Monitor Call 
Service Routine. This routine handles the users' requests 
for system services. The filing system runs m a simulated 
supervisor mode. 
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CHAPTER 1 


INTRODUCTION 


"Program development and execution are two radically 
different functions . Much can be obtained by assigning each 
function to a computer best suited for it." UDOLG 783 

Thus we can have a large central computer connected 
m a network to many small dedicated computers , providing 
"Development facilities" to the users. Most of the large 
processing occurs on the central computer and most of the 
large software also recides and executes on the central com- 
puter. 

The development systems locally provide users with 
following utilities: 

( 1 ) A powerful filing system to maintain user files . 

(2) vGood tools for manipulation of text, documents and 
program s ; e . g . 

(a ) Editors 

(b) Text formatters 

(c) Documentation preparation systems 

(3) Terminal oriented system, wmch allows interactive use 
of the development facilities. 
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(4) Facilites to maintain and transfer files on many different 
media like removable disks, magnetic tapes, cards, paper 
tapes etc., and facility to print text. 

(5) Facility to carry out large processing over the central 
computer . 

Most simple systems allow this processing to be 
carried out only in a batch mode by remote job entry. 
However modern network technology also allows an 
interactive use of the central computer. 

Such a system will have many advantages. 

( 1 ) The development system can be implemented on a computer 
of moderate size. We can have many such development 
systems connected to the central computer, increasing 
the availability of computing facility to a much larger 
number of users. Such facility is best suited for 
computer centre environments, where computer availability 
is difficult. 

(2) Separating program development and processing functions 
leads to a much more homogeneous workload to both the 
central computer and the development system. 

The central computer now mainly carries out large 
compute-bound processing. It can be tuned to give 
larger throughput for such tasks. 

Most of the processing carried out by the development 
system is a form of text processing and text manipulation 
functions. The development system can be designed for 
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these workload characteristics . 

(3) In university environment , the development system can be 
tuned to the necessities of novice programmers* e.g. it 
may implement a convenient single language environment 
for a basic programming course. 

A development system presents a very visible environ- 
ment to the users (unlike the front ends), and thus has very 
stringent requirements on 

( 1 ) User response time . 

(2) System reliability 

( 3 ) Security and protection between the users 

(4) System availability 

1.1 THE PWS-316 SYSTEM 

The PWS-316 (Programmer's Work Station*) project is an 
implementation of a development system on TDC-316 computer. 
The TDC-316 computer at I-I.T. Kanpur is connected to a 
central DEC-10 system via an asynchronous line. A high 
bandwidth synchronous line is also being installed for fast 
transfer of data between the two machines. 

The PWS-316 is intended to support many simultaneous 
users m time-sharing mode. The project is divided into 
three phases . 


* The name is adapted from the Programmer's Work Bench imple- 
mented at Bell Labs. CDOLO' 783* 
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( 1 ) The design and implementation of a time-sharing operating 
system to support many online users. 

(2) The design and implementation of network software for 
setting up communication between TDC-316 and DEC-10 
systems . 

( 3 ) The development of utility programs for supporting pro- 
gram development. 

This thesis concerns itself with the design and imple- 
mentation of the basic time-sharing operating system requi- 
red for running the PWS-316 system. 

An associated project implements the filing system 
supported by this operating system. CKUMA803. These two 
projects complete the phase 1 of the PtfS-316 project. 

Chapter 2 o f this thesis gives the hardware description 
of the TDC-316 machine. 

Chapter 3 gives the user’s view of the PWS-316 system 
and defines the virtual machine implemented by the operating 
system . It also gives an overview of the structure and 
working of the operating system. 

Chapter 4 gives the details of the operating system 
design. 

Chapter 5 describes the tools used and the methodology 
followed m the project implementation. It also describes 
the testing. 
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Chapter 6 gives the designer's comments about the 
designed operating system and proposes some extensions to 
the design. 



6 


CHAPTER 2 

HARDWARE DESCRIPTION 


The PWS-316 project is implemented on a 16 bit mini- 
computer , TDC-316. The TDC-3 1 6 system comprises of a CPU, 
mam memory, relocation hardware, a system clock and various 
peripheral equipment. Fig. 2.1 gives a block diagram of the 
TDC-316 system. This chapter briefly describes the relevent 
features of the available hardware. 

The CPU is a 16 bit bipolar machine. It contains a 
Program Counter (PC), a Processor Status Word (PSW) and 14 
General Purpose Registers (GPRs). The processor supports 
two modes. Privileged and ^on-privileged. Some instructions 
are executable only in privileged mode. Each mode has its 
own Stack Pointer (SP). The remaining 12 GPR's are divided 
into two sets of 6 registers each. At a time only one set 
can be accessed, depending upon a bit-setting m the Psw. 

In PWS-316 system, the operating system runs m privileged 
mode using one set of gPr's (called Kernel Register Set). 

The user programs execute in non-privileged mode and use 
the other register set (called User Register Set). 

The CPU has a priority interrupt mechanism with 8 
priority levels. Each device is connected to the system at 
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one of these priority levels and has its own interrupt vector. 
The CPU can be assigned any priority by setting bits m PSW 
under program control. A device interrupt is enabled for 
processor interruption only if the device has a higher prio- 
rity than the current priority of the CPU. All the control 
and data registers for the devices are addressable as memory 
locations CTDC l3. 

The directly addressable memory on TDC-316 system is 
64K Bytes. This can be accessed either as a byte, or as a 
word of two bytes. The system provides a M emory Allocation 
a nd Protection (MAP) unit which allows extending the physical 
memory space to 128-^ words. The physical memory is divided 
into 32 Word blocks. 

it is possible using the Map unit , to keep more than 
one program in the main memory simultaneously. Each program 
has a virtual address space of 8 Instruction segments and 8 
Data segments. Each segment can have a maximum length of 
4K Words (m steps of 32 Words). 

The hardware contains one MAP Register for each Virtual 
segment . By loading these registers with appropriate values , 
it is possible to relocate each segment at any block boundary. 
It is also possible to specify the access protection for each 
segment as no access, read only access or read write access. 
Any illegal memory access results m a Map-abort trap. 

The hardware contains two sets of Map registers. One 
set, called Supervisor Map Registers is used to relocate the 



9 


the memory references m privileged mode. This is used to 
run the operating system. The other set, called User Map 
Registers is used to relocate the memory references m 
non- privileged mode and is used to run user programs. Thus 
MAP unit allows facility to isolate the users from each 
other and from the operating system. It also allows the 
system to allocate the memory m discontinuous parts, and 
to implement swapping using the memory faults TDC 2 . 

The present configuration of TDC-316 contains 32K Words of 
core memory. 

The system has a clock unit, which consists of an 
ELAPSE TIMER (ET) and a TIME-OF-DAY counter. The Elapse 
Timer can be programmed to interrupt the CPU at regular 
intervals of 1 micro-second to 2 ** 27 milli-seconds . The 
TIME-OF-DAY counter, incremented every milli-second, is 
used to maintain a realtime clocklL_TDC 33. 

The system has a number of peripheral devices conne- 
cted to it . 

The DISK CONTROLLER allows upto four DISK 'DRIVES to 
be connected to the system. The controller accepts comma- 
nds to transfer a sector of data between the main memory 
and the disk. The transfer is done m Direct Memory Access 
(DMA) mode and its completion is indicated by an interrupt. 
The present configuration contains a single Disk Drive 
having 7.25 Mbytes storage capacity CTDC 33. 
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All the Video Terminals are interfaced to the system 
through Asynchronous Line Controllers (ALCs). Each ALC 
supports eight terminals (or lines). Using these control- 
lers, characters can be transmitted and received from all 
the terminals in parallel, m full duplex mode. The chara- 
cter to be transmitted is put into the transmit buffer, 
along with the desired line number. The completion of 
transmission is indicated by receipt of an AC-K character 
from that line. The ALC interrupts the CPU after either 
receiving eight characters or within 3.3 milli-sec's of 
receiving one character. The present configuration has 
two sets of Asynchronous L ine Controllers. 

Besides these the system has all the standard peri- 
pherals listed below. 

(1) A line printer with printing speed of 300 lines 
per minute. 

(2) A Card Reader reading 300 cards per minute. 

( 3 ) A console teletype. 

( 4 ) High speed paper tape punch. 

(5) High speed paper tape reader. 

The details of these devices can be found inCTDC 33. 
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CHAPTER 3 

3.1 USER* S VIEW OF THE PWS-316 SYS', EM 

PWS-316 Development System provides users with some 
basic facilities for composing, editing and maintaining 
their programs and text. It acts as a Programmer's Work 
Station . 

Each user interacts with the system through a video 
terminal. The user obtains the use of various utilities by 
a set of commands. A command processor program accepts 
these commands and starts execution of the appropriate uti- 
lity program. 

The user is provided with a powerful filing facility. 
The filing system* has a hierarchical structure, allowing 
any level of Subfile Directories (SFDg). Thus the file 
directories form a tree structure. The user can specify a 
file m the system by its path from the root of the direc- 
tory tree. Each user has a Current Directory p omter (CDP), 
which he can set to point to any directory file m the tree 
(subject to protection checks). The use can also specify 


* The filing system was implemented by Aarti Kumar at I.I.T. 
Kanpur CKUMA 823. 
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a file as a path starting from the CDP. Further,, the filing 
system also provides a comprehensive protection scheme 
based on °wner, Project partner. Others scheme. £ritc 74 * 3 - 

The user is provided with commands to list directories, 
to type files, to copy files and to carry out other such 
functions . 

a line-editor is also available to the user for editing 
files and for creating new files. 

User can give his text files for printing on a line- 
printer. A line-printer spooler prints these files in seq- 
uence . 

The system also provides commands for transferring 
files between the TDC-316 and the DEC-10 systems, and for 
submitting large processing tasks to the DEC-10 system m 
Batch mode. 

Besides these, »the user can carry out various system 

% 

functions like logging into the system, logging out and 
getting system information. 

The system recognises a privileged user by his 
Project, Programmer number . The privileged user is allowed 
various system management functions. These include creating 
new users, deleting users, changing accounting information 
and introducing new utilities m the system. This user is 
also allowed access to all the files m the system. 
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3.2 THE VIkTUaL MACHINE 

PWS-316 supports multiple online users m time-sharing 
mode. These users share the system resources like filing 
space , memory , CPU, devices etc. 

To manage these resources efficiently and to isolate 
the users from each other, a time sharing operating system 
is implemented . 

This operating system presents a virtual machine to 
the ytility Programs run by each user. The virtual machine 
presents a logical view of the various resources and devices 
to the user program which is 

(1) Simple to use. 

(2) Hides all the resource sharing aspects from the 
user. The user is not allowed any direct control 
over the devices and resources. 

(3) Protects users from each other. 

This section describes the various aspects of the 
virtual machine defined by the PWS-316 operating system. 

3.2.1 USER VIRTUAL SPACE 

The PWS-316 memory system supports segmentation with 
static linking CBENS 69X 

A segment is a logical collection of information (e.g. 
a Library of Subroutines). It is the basic entity in terms 
of which this operating system manages memory • 
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The user's virtual space consists of an I-space and a 
D-space. All the instruction fetches go to the ^-»pace, 
while all the data fetches go to the D-space. i-space con- 
tains only pure code. 

Both the I-space and the D— space are divided m 8 
segments each, called code-segments and data-segments respe- 
ctively. The code-segments are pure, and can be shared by 
all programs. The data-segments can be read only or read- 
wnte. The read-only data-segments contain constant data 
initialised at the time of loading. 

The. above scheme has a number of advantages. 

(1) I-spaces of different programs can share code-seg- 
ments containing commonly used routines. 

( 2 ) Different users executing the same program can 
share the same copy of the program's code. Simi- 
larly the read-only data-segments can also be 

3 

shared by users. 

(3) Segments can be "posted" from one User's virtual 
space to another user's virtual space for transfe- 
rring a large amount of data, efficiently. 

( 4 ) Segments form a natural unit m terms of which 
memory allocation and swapping may be done. Even 
implementation of overlay segments becomes quite 
straight forward. 
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(5) If swapping is implemented , the pure code- segments 
do not have to be swapped out. 

(6) The above scheme lends itself to a direct imple- 
mentation on the TDC-316 MAP unit, which provides 
relocation and protection hardware supporting I- 
spaoe segments and 8 D-space segments. 

In PWS-316 operating system, a program can use data- 
segments 0 to 5 for its own data. The segment 0 is called 
the Communication-Segment, and is shared by the user, the 
operating system and the supervisor for passing large amount 
of data (e.g. a file path specification). This segment is 
also used for passing arguments from one program to another, 
m program-chaining. 

The data-segment 6 is called the Stack-Segment and is 
used to maintain the user stack. When a new program starts 
execution, the system resets the stack pointer to the top 
of the stack-segment. 

The data-segment 7 contains various device registers 
and is not accessible to the user program. 

In PWS-316 system, most of the utilities are written 
as sharable programs and a single copy of their code is 
kept m the mam memory. This is shared by all users. The 
read-only data-segments are also shared. Figure 3.1 shows 
the schematic diagram of a user's virtual space. 
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The user is provided with a linking facility to divide 
his programs into logical segments (Chapter 5). 

3.2.2 USER INSTRUCTION SET aND MONITOR CALLS 

User programs are allowed the use of all non-pnvileged 
instructions m the instruction set of TDC-316 machine Ctdc ij. 
u ser programs run m non-pnvileged mode / using the register 
set 1 . 

User programs obtain the system services by making 
Monitor Calls to the operating system. 

A monitor call is made by putting the call number in 

the user register R7 and by executing a TRAP instruction. 

The arguments to the monitor call are passed through the 

user registers. Uong arguments are passed by putting them 

a 

m the communication-segment , and by passing/pointer to them 
m a user register. Results of the monitor call are also 
returned m the user registers and through communication- 
segment. 

The user program is expected to save the values of the 
registers used m a monitor call. These values can then be 
restored after the monitor call. System provides a macro- 
library for performing these functions (Appendix /Sj ) . These 
macros perform the required register saving, monitor call 
linkage and restoring of the registers. 
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3.2.3 PROGRAM CHAINING 

The virtual machine provides facility for CHAINING 
programs. This means, one program can start execution of 
another program by a RUN monitor ca.i.1. The old program is 
lost. Arguments can be passed to the chained program through 
the communication-segment , which is "posted" intact to 
the new program. This facility allows a number of programs 
to work m sequence towards completion of a task. 

3.2.4 COMMAND PROCESSOR aS A USER PROGRAM 

The Command Processor is a special user program which 
runs when no other program is running. 

The command processor obtains command lines from the 
user terminal. It parses these commands, and inserts 
default parameters before executing the command. The command 
processor may directly service the command using various 
system information monitor calls. Alternately it may chain 
to an appropriate program, passing arguments in the communi- 
cation area. Typing directories and files, copying files, 
editing are all carried out by separate utility programs to 
which command processor chains. 

Error messages are also displayed to the user by the 
command processor. When a user program is aborted, the 
system automatically chains to the command processor, passing 
it the appropriate error number. The command processor then 
displays the required error message. 




19 


3.3 OVERVIEW OF THE STRUCTURE AND THE WORKING OF THE 
OPERATING SYSTEM 

Each user m the operating system is associated with a 
process. Besides these there are some system processes. 
Process is the basic functional unit m which operating 
system organises its activity. Operating system manages the 
processes such that they run independently of each other and 
interact only m a well defined manner. The single CPU is 
multiplexed between all the processes. 

The processes are identified by three states , as shown 
m Figure 3.2. 

(1) Run ; Executing on the processor. 

(2) Ready : Waiting for the processor. 

(3) Blocked : Waiting for a resource. 

All the ready'* processes are kept in a Ready- Queue 
(RDYQUE). One process is "running" at a time. This is 
called the Current Process (CP). 

System has a hardware clock (ET) which interrupts the 

system at regular intervals. On each clock interrupt, the 

of 

CPU is allocated to a new process. The state/the CP is 
saved and it is inserted at the end of the RDYQUE. The 
scheduler then selects a process for executing on CPU. The 
scheduling discipline used is First- In- First-Out . The 
selected process is made the current process, its state is 
restored (this involves loading various hardware registers 




with appropriate values), and control is transferred to that 
program . 

While running, a process makes monitor calls for 
obtaining system services. Some of these calls result m 
the current process getting blocked, as the service is not 
available . The state of the process is saved and its status 
is changed to "blocked". The scheduler is then called to 
select a new process for running. 

When the service becomes available (generally indica- 
ted by an interrupt from the hardware device or by a signal 
operation by another process), the blocked process is 
awakened. The status of the process is changed to Ready 
and it is inserted at the end of the RDYQUE. 

The process synchronization primitives provided are 
BINARY SEMAPHORES and EVENT BASED SIGNALS AND WAITS. 

The operating system is designed as a hierarchy of 
three layers. 

(l) The KERNEL is the innermost layer of the operating 
system. It provides the basic mechanisms for imple- 
menting processes , the processor allocation to these 
and synchronization between the processes. 

It also provides the basic memory management 
functions for running each process in its own 
virtual space . 


(2) The middle layer consists of Device-Subsystems and 
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Error-trap handlers. 

A device subsystem consists of an interrupt 
routine to handle the device Interrupts, and a 
set of service routines for obtaining logical servi- 
ces from the device. 

The system processes are also implemented at 
this layer. System processes carry out those system 
functions which take a long time to complete. Sys- 
tem processes are scheduled like user processes 
(e.g. Line Printer Spooler). * 

(3 ) The topmost layer contains the Monitor Call Handling 
routine. 

This routine obtains the monitor call arguments 
provided by the user process and makes appropriate 
routine calls to the device subsystems for services. 
It also makes routine calls to the kernel for block- 
ing the process and for other synchronisation func- 
tions . 

All the above layers are executed m privileged mode 
using the Kernel Register Set. They run at highest priority 
and are unmterruptable. Thus they naturally constitute 
critical regions. 

Besides these the operating system contains the file 
system routines, which are implemented as a supervisor. The 
supervisor has a shared data structure and consists of sharable 



reentrant routines. These are used by various user processes 
concurrently. These procedures use the semaphore mechanism 
provided by the above three layers for implementing the 
critical regions and for synchronisation. These routines 
run m non-pnvileged mode using the user registers and get 
blocked like the user programs . The supervisor is implemented 
by simulating a supervisor mode. 

The system also has a booting program which loads the 
operating system, initialises the system and brings m various 
utility programs into the mam memory. 
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CHAPTER 4 

STEPWISE DESIGN OF THE OPERATING SYSTEM 

The PWS-316 operating system is designed as a set of 
modules. These modules form a hierarchy as shown m Figure 
4.1. The relation defining the hierarchy is "routine call" 
CPARN 783. 

The following sections describe the system modules, m 
a bottom-up fashion. Appendix A gives the program listings 
for each module. 

4.1 PROCESS MANAGEMENT KERNEL 

Process Management -Kernel implements the processor 
allocation and process synchronization for a fixed number of 
processes, whose state information is always in main memory. 

A process is implemented as a data structure called 
PROCESS-DESCRIPTOR. It contains the following information: 

(1) Process Status (running, ready or blocked). 

(2) Saved state of the process when not running. 

(3 ) Memory allocation information and memory map for 
the currently executing program under this process. 

(4) Blocking information: The cause of blocking and 
some associated parameters. 
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FIGURE 4.1 
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( 5 ) System information: 

(a) Flags indicating the resources assigned to the 
process . 

(b) Current mode of the process 5 User or Supervisor 

(c) Flag indicating whether D- space is enabled or not. 

(6) The user information: name, user number, current 
directory pointer (CDP) etc. 

(7 ) L mks to insert the process m various process 
queues . 

The module GLOBE defines the Process Descriptors . 

The module QUEUE implements queue management for all 
process queues m the system. Routines INSERT and REMOVE 
are used to insert and remove processes from a queue, respe- 
ctively. Routine ISEMPTY indicates whether a queue is empty 
or not . 

RDYQUE is the queue of all ready" processes. 

Module CLOCK gives routines to manipulate the system 
clock. These allow initializing/ starting, stopping and 
reading the clock. 

Module EVENT is the heart of the process management 
kernel. This module itself is designed as a hierarchy of 
routines as shown m Figure 4.2 twuLF 753. 

The innermost routines are SAVESTATE and LOADSTATE. 
Routine SAVESTATE saves the state of the Current Process (CP ) 
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xn its process descriptor. The routine LOADSTATE loads the 
state of the specified process onto the hardware. This . 
includes : 

( 1 ) loading GPR values . 

(2) Loading User Map Registers with process memory map. 

The next level consists of routines SCHEDULE and CLOCK- 

BLOCK. 

The routine SCHEDULE selects a new process for running 
on CPU. Process at the head of RDYQUE is selected, giving 
First-In- First-Out scheduling policy. The state of this 
process is loaded and the process is "dispatched". The dis- 
patch operation resets the system stack to empty and loads 
PC and PSW of the dispatched process on the hardware. It 
also enables the Map unit appropriately. 

The scheduler dispatches a null process, if RDYQUE is 
empty. N ull process is always xn "ready" state. Null pro- 
cess is implemented by the module NULL. 

The routine CLOCK-BLOCK is an interrupt service routine, 
invoked at each Clock Interrupt. It saves the state of CP 
and inserts thus process m RDYQUE. Then it restarts the 
clock and calls SCHEDULE to dispatch a new process. 

The routines above this level implement Process Synch- 
ronisation primitives. The basic routines, BLOCK and AWAKE, 
have the following action. 

Routine BLOCK saves the state of the specified process 
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and changes its status to "Blocked". The routine AWAKE inserts 
the specified process in RDYQUE and changes its status to 
"ready". Some operating system routines directly use primi- 
tives BLOCK and AWAkE for synchronization (e.g. disk manager). 

The next level contains routines EWAIT and SIGNAL, which 
are EVENT based primitives for synchronoziation . Atmost one 
process can wait an event at a time. The routine EWaIT blocks 
the specified process, and marks it as "blocked" on the 
specified event. When the event occurs, a SiGNL operation is 
carried out. The routine SiGNL checks if the specified process 
is blocked on the specified event. If so, then the process 
is awakened, otherwise no action is taken. 

The primitives EWAIT and SIGNL though not very general, 
are used quite frequently m this design as they have signi- 
ficantly lower overheads than semaphores. 

The most general synchronization primitives implemented 
are BINaRY SEMAPHORES . Each semaphore has a boolean flag and 
a queue of waiting processes associated with it. 

p seudo-code m Figure 4.3 shows the action of the 
semaphore primitives. These include INITSEM, RESETSEM, 

WaITSEM and faIGNLSEM . 

A commonly used method for handling service requests 
from a user process is as follows s 

(i) If service can be satisfied, it is completed. Other- 
wise, the requesting process is blocked using 
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routine INITSEM(sEMNO)= 
begin 

IN I TQUE ( SEM0 f SEMNO) ) ) ? F UG C SEMN03 i- 
end; 

routine RESETSEM ( SEMNO) = 
beain 

FtGrsEHNO]>false 

end; 

routine WATTSEM(SEMNO)= 
begin 

if FLGtSEMNO] then 
begin 4 

FtiGfSFMNOiJsFAliSE; 

RETURN 


end 

else 

oegin 


end? 


end 


INSERTCSEMQCSEMNOl #CP) ; 
bLOCKCCP) 


routine si gnlsem c semno ) * 
begin 

if TSEMPTY (SEMQ f SFMU03 ) then 
FhGCSEMNOlJ=true 
else 
begin 

AWAF Ef FIRST fSFMOtSENNn] ) ) 
RETURN 

end 

end; 

FIGURE 4.3 BINARY SEMAPHORES 


TRUE 
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EWAIT prxmxtave . The user's Program Counter is 
"instruction backed" by one instruction so that on 
awakening the process may retry for the service. 

(ii) When service becomes available , a SIGNLT operation 

is carried out. This awakens the process rf blocked. 

The awakened process then again requests for 
the service , which is now available. 

4.2 MEMORY SYSTEM 

The Memory System allocates memory to the utility 
programs and the user data areas. It also maintains a table 
of available utilities and sets up the user's segment-maps 
when the user runs a new program. 

The physical memory map of the system is shown m 
Figure 4.4. The TDC-316 hardware can support a maximum of 
128K Word storage. Present configuration has 32K Words of 
storage . 

The available memory is divided into 3 parts ; 

( 1 ) The operating system area s This contains the 
operating system and supervisor. It also contains 
the system stack, the device interrupt vectors 
and the system processes. 

(2) Utility area; Utilities m PWS-316 system are 
implemented as sharable, pure programs. All 
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utilities are resident in main memory and a single 
copy of their code is shared by all users. The 
utility area contains the code-segments and the 
read-only data segments of all programs* 

(3) User data areas The remaining portion of mam 
memory is called User Data Area. Presently the 
system has a fixed partition scheme for memory 
allocation in which User Data ..Area is equally 
divided between the user processes to form each 
user's Work Space. The data segments are set up 
from the user's work-space. 

The system maintains a table of all utilities m the 
mam memory called Active Program Table (ACTTAB), It con- 
tains the following information: 

(1) Program name 

( 2 ) Virtual entrypomt of the program 5 p C is initialized 
to this value at the start of execution. 

(3 ) Length of D-space required by the program : This 
excludes the stack segment and read-only data 
segments . 

( 4 ) Protection Code s This is used to restrict the 
availability of some programs only to some users. 


( 5 ) I-space-map for the program 
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(6) information for setting up space maps The length 
of each D-space segment and the address of read- 
only data segments. 

The module MEMORY implements the memory system. 

Routine DdUsrMAP loads the memory maps for the current 
user-program on the hardware. I-space map is taken from the 
ACTTAB while the D-space map is available m user's Process 
Descriptor . 

Routine SETUsr is used to set up the user's process 
descriptor for execution of a new program. The D-space is 
set up m user's work-space by allocating memory to Data 
segments m sequence. Read-Only Data Segments are not set 
up, as a single copy of these is provided by the system, and 
is shared by all processes. A pointer to the appropriate 
I-map is also set up m the p rocess Descriptor. 

The remaining space m user's work area is used to 
create the stack segment. The stack pointer is initialized 
to the top of this segment. The routine SETUsr also initia- 
lizes the PC to the virtual entry point specified m the 
ACTTAB. The GPR's are initialized to 0. Further, the D-space 
enable bit in process Descriptor is turned on to signify that 
the process uses both T and D-spaces . 

it is also possible to run a user's private programs 
by loading them m his work-space. The routine SETPRIV sets 
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up the I-space map for the loaded program , in the process- 
descriptor. The D-space enable bit is turned off to signify 
that the program uses only the I-space. 

When program wishes to execute a new program 4 it makes 
a Run monitor-call , after placing the program name m commu- 
nication Area. The routine SCAN searches the ACTTAB table 
to find the appropriate entry. It also carries cut the 
protection checks. A Linear search is used as the table 
size is small. 

Besides these, module MEMORY contains a few other 
routines . Routine SETCOMM is used by the schedules to make 
the Communication Segment of the Current Process available 
to the system as data-segment 6. The routine SETSUP is 
used to overlay the user virtual space by supervisor virtual 
space for running the filing system (See supervisor impleme- 
ntation ) . 

, The module SET ACT implements loading of utility progr- 
ams and setting up of ACTTAB table. It also allocates user- 
work space. These operations are done at the time of 
starting the system. 

The utility programs are stored on the disk as files. 
These files are kept m a special directory owned by the 
privileged user. The first block of each file contains a 
Header Record. The Header Record contains all information 
required to set up an aCTTAB entry. It gives the name of 
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the utility , the length of D-space required by the utility, 
the lengths of all code segments and the lengths and nature 
(read-only or read-write ) of each data segment. The rest of 
the file contains the utilities code segments and read-only 
data segments m load format. 

The routine GETUTILITY opens the required utility 
file and sets up the ACTTAB entry for that utility using the 
Header Record. It also allocates memory space for the utility 
m utility area. It then loads the utility code— segments in 
contiguous memory blocks. Read-only data segments are also 
loaded alongwith. 

At the time of starting the operating system, the 
booting program calls routine GETUTILITY with utility names 
provided by the operator. 

After all the required utilities are loaded, the 
remaining area is equally divided among user processes. The 
process descriptor is loaded with aporopnate values to 
reflect this assignment. The above function is carried out 
by the routine ALLdcusR. 

4.3 ERROR TRAPS 

All the error traps result in the abortion of the 
current process. The user process returns to the command 
processor program. 


The user PC at which abort occurs and the nature of 
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error are passed as parameters to the command processor. 

The command processor displays the appropriate error message. 

The module ERROR implements these functions. 

4.4 DEVICE SUBSYSTEMS 

Device subsystems control the device hardware. They 
also supplement the functions provided by the device hard- 
ware to give user processes a logical view of the devices. 

For example, a device system may use buffering to allow 
overlapping of device operation and computation. 

Each subsystem is implemented as a module having a 
private data structure (e.g. buffers , status words etc.). 
There is a set of conditions associated with the subsystem 
on which user processes can get blocked (e.g. input buffer 
empty ) . The sub-system recognises a set of predefined events 
which it signals. These signals awaken the blocked processes. 

Each sub-system consists of three sets of routines s 

(1) Device Driver 1 This routine initiates the action 
of the device. 

(2) Device Interrupt Routines This routine is executed 
when the device hardware indicates completion of 
some action by an interupt. 

The routine manipulates the data structure 
(e.g. enter the received character m buffer or 
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change status ) and may initiate the device action* 

It also recognises events and signals them using 
the SlGNL primitive provided by the kernel. 

(3) Device Service Routines: The device service routines 
are used by the user processes to obtain the logical 
service from the sub- system (e.g. get a character 
from TTY input buffer). 

These routines also manipulate the data 
structure. They may block the user process depen- 
ding upon some conditions associated with the 
data structure. 

B esides these there are error interrupt routines which 
handle errors from the device hardware. They indicate the 
error to the console and wait for corrective action to be 
taken. They may also abort processes wanting the service 
of the device. 

Since both the device mterrup routine and the device 
service routines access the data structure concurrently , 
it is necessary that they run in "mutual exclusion". This 
is achieved by running both these routines at processor 
priority 7. Hence these routines are executed uninterrupted 
and act as critical sections . 
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4.4.1 TTY SUBSYSTEM 

This subsystem handles the video terminals connected 
to the system through Asynchronous L-ne Controllers. 

The TTY SUBSYSTEM maintains circular buffers for input 
and output on each line. Each line also has a status word. 
The subsystem consists of the device driver routine TRANSMIT/ 
the device interrupt routine SCANNER and device service 
routines GETCH, PUTCH, ECHO / NOECHO / INEMPTY / OUTFUL, LINEIN, 
RESET , FLUSIN ani FLUSOUT. 

The subsystem recognises three conditions 

(1) Input buffer empty 

I 

(2) Output buffer full 

(3) No CRLF characters in input buffer. 

These are used to block the user processes . The sub- 
system signals appropriate events when these conditions 
become false. 

4.4.2 DISK SUBSYSTEM 

The disk subsystem* accepts requests for reading and 
writing of disk sectors . The disk manager maintains a queue 
of all disk input-output requests and services them one 
after another. 

The disk subsystem consists of the disk driver routine 
DRIVER/ the disk interrupt routine DATATRANs and the service 


* implemented by Aarti Kumar CKUMA 82tX. 
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routine ENTERREQVEST. Routine ENTERREQUEST is used by the 
user processes for requesting disk operations. 

Each request results m the blocking of the requesting 
process using primitive BLOCK. On completion of the request , 
the interrupt routine DATATRANs awakens the blocked process 
using primitive AWAKE. The implementation details of this 
module can be found m UKUMA 823. 

4.4.3 SYSTEM PROCESSES 

The system services which get blocked m their execu- 
tion and which take a long time to execute are implemented 
as system processes (e.g. swapper/ loader, spoolers etc.). 
System processes are scheduled alongwith user processes . 

System processes are allocated memory m the operating 
system area and they communicate with the operating system 
directly for transfer of data. 

The current design contains a single system process, 
the L meprinter Spooler*. Details of its implementation can 
be found m CKUMA 823. 

4.5 SUPERVISOR MODE IMPLEMENTATION 

The file system consists of a shared data structure 
and a set of shared reentrant routines. These routines are 


* implemented by Aarti Kumar CKDMA 823- 
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used by the user processes to carry out various file system 
functions . 

Critical regions are implemented m the filing system 

code^ to maintain consistence of the shared data structure. 

a 

Thus, user process may get blocked before entering/critical 
region. Also/ when the file system requires some disk 1/0/ 
the user process gets blocked till the request is completed. 

To implement blocking of processes executing the 
file system code/ it would be preferable to run the file 
system code m user mode. 

1 It is common in some systems for supervisor code to 
be made part of each user process. User address space inclu- 
des privileged code and data. One motivation for such 
design results from the fact that supervisor services take 
considerable amount of time. In this fashion, a user process 
m the midst of a supervisor call can be interrupted (or 
blocked) to allow other processing m a manner essentially the 
same as when user code is interrupted (or blocked). However, 
this leads to security flaws." CPOPE 753 

°ne solution to this problem is to have a supervisor 
mode with its own virtual space and register set which is 
different from user mode and kernel mode. Then kernel can 
block processes in supervisor mode TOPS 10 . However TDC- 
316 hardware does not permit this. 
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In PWS-316 the supervisor mode is simulated by overla- 
ying the supervisor virtual space over the user virtual 
space whenever the user makes a file system request. This 
can easily be done by loading the supervisor segment map 
onto the relocation hardware in place of the user map. 

The overlaying of supervisor is done transparently to 
the user when he makes a request for a file system service 
using switch-to-supervisor monitor call. After loading the 
supervisor map. the monitor call handler passes control to 
the supervisor at a fixed entry point. The user _and the 
supervisor modes share the communication segment and the stack 
segment m data-space. Arguments are passed through the 
stack while long file specifications are passed through the 
communication segment. 

On completion of the service, supervisor makes a 
return-to-user call which restores the user‘s virtual space. 

M odule SUPERVISOR contains the code for the implemen- 
tation of supervisor mode. The details of file system design 
can be found m tLKUMA 823". 

4.6 MONITOR CALL HANDLING 

The user process makes monitor calls using the TRAP 
instruction. Arguments are passed through the user registers. 
Long arguments and results are passed through the communica- 


tion area 
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Module SYSCAL implements monitor call handling. The 
interrupt routine MONITOR is invoked whenever user makes a 
Trap instruction. This routine makes routine calls to the 
various subsystems and uses kernel primitives for blocking 
and awakening the processes. The communication segment is 
available as segment 6 of the kernel D~space. (On each 
schedule this segment 6 is made to point to the seg 0 of 
the new CP # using routine SETCOMM). 

4.7 BOOT I IMG THE SYSTEM 

The booting of PWS-316 operating system is carried out 
m two parts. 

The first part consists of loading the operating 
system from a predefined area on the disk into the main 
memory. This is done by program LOAD. Program LOAD itself 
is read into the mam memory from a paper tape. After 
loading, program LOAD transfers control to program BOOT in 
the operating system area. 

Program Boer carries out the following sequence of 
actions . 

(1) All the modules of the operating system are 
initialized. 

(2) Various utilities are brought into the main 
memory under operator's commands. The Active 



Program Table ( ACTTAB ) is initialized and the 
User Work Areas are set up* 

The user process -descriptors are initialized to 
run the command processor program under the user 
number (0,0). This number signifies that the only 
operation allowed to the user is LOGIN. 

The processes are inserted into the RDYQUE and 
routine SC HED ULE is called to despatch a process. 
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CHAPTER 5 

IMPLEMENTATION AND TESTINGS 

The programming language BLlss-11 was selected for 
implementation of the PWS-316 project. BLIss- 11 has many- 
desirable features which make it suitable for an operating 
system implementation on TDC-316 jHWXJLF 713. 

(1) BLISS-11 allows access to all the hardware features, 
permitting the coding of entire operating system in 
BLlss-11. 

(2) The object code generated by Bij.ss-11 does not 
require any run time support. 

(3) it gives control over the representation of data 
structures and methods to access them. 

( 4 ) it has a flexible range of control structures 
(including recursion and coroutines). It encourages 
program structuring and readability. 

(5) It allows modularization of the system into 
separately compilable submodules. Each module can 
have its private data and a set of routines. Some 
of these data and routines can be made global 
allowing access to them by other modules. 
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The modularization facility gives a powerful 
abstraction mechanisms and allows program structur- 
ing. It also facilitates debugging. 

(6) The Bliss- 11 compiler is very highly optimizing 
compiler . 

(7 ) Cross software is available for using the code 
generated by Bliss-11 compiler on TDC-316 system. 

The support facilities available for implementation of 

PWS-316 project consist of a BLISS-11 compiler, a cross- 
+1 

assembler giving TDC-316 object code and linkers LNKx-11 
and NEWLNK. LNKx-11 accepts object code of separately comp- 
leted modules and generates absolute object code m a linear 
virtual space. This linker was used to generate the operating 
system code. NewLNK 4 ^ allows generation of sharable code by 
relocating the instruction and the data references into sep- 
arate I and D-spaces. It also supports segmentation and 
allows grouping of logically related objects into sections. 
This software runs on the DEC-10 computer at our installation. 

A facility to download the object programs from the 
+2 

DEC-10 system was also available. A machine level debugger 
call DEBUG was written as a part of this project. It gives 


-*1 Developed at NCSDCT , TIFR, Bombay. 

+2 Developed by George Paul at Computer Centre, I.l.T. Kanpur. 
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facility to examine and load memory locations and to set 
breakpoints m the loaded programs. 

The operating system was designed as a hierarchy of 
layers |DIJK 68, DIJK 72^. Each layer was implemented as a 
set of modules. The system was decomposed into modules 
following these criteria s 

(1) The interaction between modules must be minimum, 
it must generally be m the form of routine calls. 

(2) The routines working over common data are placed m 
the same module. 

(3) Logically related functions are grouped into a 
module £BERG 81 , PARN 72^. 

First the specification of the system and its structure 
were decided. The system was then implemented bottom up. For 
each layer the modules were defined and these definitions 
were "filled up" with code. 

The testing of the system was also done in bottom-up 
fashion, alongwith coding. Each module was tested by writing 
a test drives for the module. The debugger was used to trace 
the control flow and its effects. The bottom-up order of 
testing has the advantage that when a module is being tested, 
it may use the lower level modules which are already tested 
and available £ZELK 79^. 
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The implementation of the Pws-316 operating system 
has not been fully completed. However the basic operating sys- 
tem mechanisms have been coded and tested. The process-mana- 
gement-kernel , the memory system,, the device subsystems and 
basic monitor-call handler are available. 

The unfinished portions of the operating system are 
outlined below: 

( 1 ) System management functions like Login, Creating 

new users. Accounting etc. have not been implemented. 

(2) The booting program does not load the utilities from 
the disk. Instead they are downloaded frcm the 
DEC- 10 system. This change affects the module 
BOOT and the module SET ACT. 

( 3 ) Most of the utilities are not available. A 
primitive command processor and a set of demons- 
tration programs have been written. 
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CHAPTER 6 

CONCLUSION. 


The implementation of PWS -316 system is not complete 
enough to allow any performance evaluation. However our 
experience with the design of the operating system has 
led us to the following conclusions. 

( 1 ) It is possible to develop operating systems in 
reasonable time periods # if proper methodology 
is followed in its design and implementation. 

(2) A good implementation language and tools are 
mdispensible m implementating such systems. 

'The language BLISS- 11 xvent a long way m reducing 

our programming burden# allowing us to concentrate 
on the system structure. 

( 3 ) The structure of the system strongly influences 
the ease of its implementation and testing. It 
also affects the system extensibility. 

The present design of the PWS-316 operating system 
has few limitations. They are outlined below. The possible 
extensions to the system are also indicated. 

( 1 ) The system has a very primitive memory management 
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system. All the utilities are resident in main- 
memory. Also, the user work space is assigned by 
a fixed partition scheme at the time of starting 
the operating system. This scheme is very waste- 
ful from memory utilization point of view. 

The memory management scheme for the system 
can be extended to include swapping of utility 
code. The allocation of data space for the user 
processes can also be done dynamically. 

(2) The system has a single queue of ready processes. 

All the processes are kept at the' same priority 
level. 

With more system processes (for TDC-DEC 
communication, loading, swapping etc.), it may be 
desirable to have many queues according to the 
process priority. A different scheduling policy 
can also be implemented. 

(3 ) The synchronization primitives implemented are 
quite restrictive. Some form of mailbox facility 

to pass messages alongwith the signals is desirable. 
Also it may be advantageous to use a uniform 
mechanism for all synchronization. 

The get-resource and put -resource primitives 
suggested by Shaw can provide an adequate synchro- 
nization mechanism ^HAW 74, SHAW 7s|. 
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**************************************** ***************** 

* MODULE : PARAM.BU * 

* WlfROHR ; Paritosfi K, Pandva. * 

* DATE ! ?4/7 /gP * 

* function: This module defines all the system * 

^ m ^ g J*! <JJ ^ 

#♦♦************************#*****#*****#***********;***#**£ 


:bo file containing all the system parameters, 

th SYSTEM PARAMETERS START WITH fc* % 


tlDNUMBER=3S, 

ifcQNUM=3$, 4NO OF QUEUES IN SYSTEM=RDYOUE*SEMAPHORE QUEUES 

ilRDYQUE=6$, JNQ op READY QUEUE 

&NULLPROC=0$, l NULL PROCESS NO, 

*£STKLIM=flOOO$, iTOP LI*IT OF SUPERVISOR STACK 

i&BLIM =6$, INO OF CLASSES FVENTS 0 TO t&BLTM-l 
i*SEHNO =2S, INO. Of SEMAPHORES 

'd&SEMQ =1 $ f 1 START OF SEMPHORF QUEUES 
»&SF,MBLK=60S , ’EVENT NO, FOR SEMAPHORE BLOCK 
iSN0LTNES=8$, INO, OF TTYS CONNOTED 0 TO NQLINES-1 
i&IN8SZ s 2Q$ , ‘SIZE OF TTY INPUT SUFFERS 

«&0TB5Z-20$ , ISIZE OF TTY OUTPUT BUFFERS 

»&TMPBSZ=20$, JSIZE OF TMP BUFFER IN TTY SUBSYSTEM ^ „ 

«&TTYCPROCNn)5PROCND+2$ # ‘PROCESS 0 TO 4 APE SYSTEM PROCESS 

,STTTY(LINE)=LINE-2’$, »*P ROCESS No FOR GIVEN TTY LINE, 

«&PRNQ=4$, ‘NO, OF PROGRAMS IN ACTIVE PROGRAM TABLE 

«&COMM(ADDR)*( #140000+ ADDR) S i i ACCESS COMMUNICATION SEG, 
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4 ********************************* ********** ************* 

* modhlf : deffii. 

* AUTHQUR : Paritosh K. Pandya. 

$ D^TK * 7 A/1 / 8? 

* FUNCTION: This module defines the trap call and 

*** s**###***** #* ******* ****|$**** * ********* ***** * *********% 

'sDEFFILE ASSIGNING VALUES TO TRAPS ANO EVENTS % 
nacro 


TRP0=0S, 
TRP1-1 S, 
TRP2=2$, 
TRpl= 3 $, 
X«P4=4$, 
TPP5s*5$, 

TRP51=51$, 

T»p55=S5$, 

T d P56=56$, 

T»P57»57$, 


1INEMPTY TTY 
JGETC W txy 


EVT0-3S, 
EVTI-4S f 
EVT2s5$ f 
EVT60*60$: 


J TTY 
l TTY 


INPUT BLOCK (GETCH) 

OUTPUT BLOCK ( D UTCH) 
iWATT FOR EOLN TN TTY INPUT BUFFER 
•SEMAPHORE BLOCK 


* * * -* * 
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**************************** 

* MODULE ! GLOBf 

* ahthuur : Paritosn K* Pi 

* D«TF S 24/7/82 

* FUNCTION: rnis module d< 


****** * * * * * t ** ** *** I *** *** ** 

LOBES 

OPAL DEFINITIONS AND INTTTALIZ 


module GLOBES 
* GL 


begin 

process descriptor definition 
jmemory management extension 

! UPDATE SEGMENTFD MEMORY SYSTE 
%EXTRRNAL MACRO . 

&&DNUMBFR 

require PARAM.B1 1 » 
macro 

} PROCESS DESCRIPTOR DETAIt 
DSIZE=80$, ‘SIZE OF R 

iDEFINJTION OF VARIOUS F'i 

MOB STATt 


JBSTS=0$, 

JBFLNK»2S , 
JBBLNK*4$. £ 
JBBLKTl)=6S , 

JBPCsRi, 

JBPSslOS, 

SUPPC»12$, 

SUPPSsl4$ t 

JBTTME=J6$, 

JBGPRslgs, 

JBIPTRs32S , 

JBDSEG»34$, 

JBFLG«66$, 

JBDORGS68S* 

JBDLEN*7Q$ # 

JBPPNs72$, 

JBNAMEs74S,. 

JBPRNAMF.sRZi 


ILINK FOR 

jblocking 


ICPH TIME 

iUSER I SI 
•USER D Si 
•FLAGS AS! 
•ORTGTN Q1 
•IENGTH O' 
•USER P,P' 
•USER NAMl 
‘NAME OF 1 


1FLAG FIELD DEFINITIONS 


SUPBITsO, IS# 
DSPBITsl » 1 $ , 


•USER/SUPj 
ID-SPACE 1 


i DEFINITION OF JOB STATUS 
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ra§i§ s 9f' 

ROYSTSaslS, 

&LKSTS=2$; 


structure DESC CJOB,FIEWU*( ,DESC+.JDB»i)SlZE+. FIELD) s 
£ m ^2 CKSS ifeDNlJMRER/? ] ? M 

! PROCESS DESCRIPTORS. 


ARRAY OF 


global CP, GLEPC.GLEPS, JIFFY, MPCSRJ 
global routine INTTD8= 
begin 

iocr I from 0 to ( tl*DKUMBER*DSIZE) »2 by 2 do 
( PRQCESS+ , T ) »0 

end? 


end 

eludom 



s 


i *********f****;M*#** ************************************* 

* * MODULE I QUEUE * 

* AUTHOUR s Paritosh K. Pandya, * 

* D^TE : 74/7/82 * 

* FUNCTION s tms module implements queue management * 

* functions for all process queues in the * 

**************#*****$********♦****♦**************»*******% 

module QUEUE (NOT. 1ST)* 

% Generalised queue handling procedures 2/5/82 P.K.PANDIA % 
begin 

require PR0C02.RU? * DEFINITION OF PROCESS DESCRIPTOR 

%EXTERNAL M»CRO &GQNUM i HQ O p QUEUES % 
require PARAM.Bil; 

word own VECTOR QUEFSTlQUELSTt QUECQUNTUiONUMl ; 
global routine IWTTOUECOUENO)= 
begin 

■ UEFST [^UENOj^UELST f.QUENOJ *-l ? 


end; 


UECOUN' 


qlobal routine TNSERT(QUENQ # PRQCNO}* 
beqin 

%INSERT GIVEN PROCESS AT THE END OF RDTOUEUE % 
if .QUECOUNT r.QUENOl eql 0 then 
begin 

OUEFST L, QUENOlS.PROCNO; 

QUELST C . QUENQ] s.PROCNO? 

QUECOUNT t.QUENOJ =1 ; 

PROCESS T .^ROC NO, JRFLNK3 e PROCESS t*PR0CNO,JBBLNK3 ®»i 

end 

else 

begin 

lOCcll TMp * 

QUECOUNT UQUEN03*. QUECOUNT [.QOENOl+1; 
T w P=.0UFLSTr.QUEN03 ; 

QUELST [ . QTIEN01 = . PPQCNO | 

PROCESS t. PROCMO , JBFLNKJ **■! ; 


end; 


end 


PROCESS L. PROCNO » JR8lfNK3 a .TMP; 
PROCESS C«TMP#J8FL M Kl s .PROW 


qlobal routine FIRST(QUENO)» 

beq |oBTAIN THE FIRST ELEMENT OF RDYQUEUE AND REMOVE IT % 
if .QUECOUNTC.QUENOl eql 1 then 
b60 in 

QUECOUNT l , QUEN03 *0 ,* 



return .quefstc.qi 


end 
else . 
heqin 

local TWPi , tmP2j 
0”KCOUNTC*6nEW0^ 
TMPl=i.QnEFST[.OnE! 
onErsT£.onENo!=.p! 
T M P2s.QUEFST t .CUE 1 
PROCESS r.TMP2,j8B! 
return .TMPt 

end 

endi 

global routine tsfmpiy (quenh) 
begin 

if .QUECOUNTC.OnENOl eq 
return -t 
else 

return 0 

end? 


%GL08AL ROUTINE SHOWOUECQUENO 

BEGIN 
extern, 
MACRO i 

PROMPT 
IF .QUI 
MES.' 
ELSE 
BFGTM 
r-OCAi 
TMPs 
INCR 
CD 
T 

END 
END? % 

global routine INITOI* 

beCI |INITIALZATION ROJITINEI' 
Incr I from 0 to **QNUM 
INTTOUEC.I) 

end? 


end 

etudom 
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% 


1 ffiS”™ \ ?4/7/!! h K< PandVa - 

» function: TM! modul. gives basic functions to 

module C ^Sc^"o*^s"^”********** !^ ** S ’*’* S? ’*"” ,, ’********«**' , * 

% MODULE CTdOCK 


begin 
bind 


P.K.PAMDYA 


4 / 7 / 82 % 


FROM EVFNT 


CKCSR=#777542, 

CKETL?=#777540, 

CKETH*#777546, 

CKVEC=#134; 

macro 

IENB»6 , i S » 

STET*8,1$, 

MODEsRelSf 
RFET=13,1$? 

external CLOCEBLOCK? 
external JIFFY* 

global routine RESTCLK* 
begin 

CKCSR«STET>*1 
© ndl * 

global* routine STOPCEK* 
begin 

CKCSR<fSTET>*0 

end? 

global routine readclk* 
begin 

CKCSR<REET>=1? 
return -C.CKETL) 
end; 

global routine STRTCLKs* 
begin 

CKCSR*#1530 

global * routine 1NIT04P 
begin 

:KVEC*CLQCKBLDCKr 

'CKVEC+2)s#t?40; ?<SUP MODE »REGO,PROI 5> 
1KETH® #377 ? 

;keti*=-. JIFFY? 
end; 


end 





eludom 


9 


% ************************************************$***** 4 ** 

* MODULE i NULL 

* &yiS 0Tm 1 Sfrltosh K. Pandva, 

* DATE ? 24/7/82 

* JUNCTION? This module implements the null process. 

Jf ♦ ♦ ♦ # # ♦ * ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦ <♦* ♦ # # ♦ ♦ ♦ ♦ * ♦ ♦ ♦ ♦ ♦ * ♦ $ # ♦ ♦ ♦ J)> ♦ $ $ $ # $ $ $ $ $ $ $ $ 

module NOLL= 

becjln « 

bind VALs#*, 777776? $REG 7 OF TDC 

%EXTERNAL MACRO 

&SNULLPROCsO$? 1 
require PARAM.B1 1 ? 

require PR0C02.BH? 

global routine TMTOi« 
begin 

switches UNSAFE? 

PWESS f S&NULl-PPQC , JBPC1 *M ULL? 

?cSS fi 5?J^H^ p f t °^ TBPs1 * #14Qf) f i<WSR MODE REG SET 1 PK 
cSET NULL PUQC NAP% 
begl n 

local TORG, TMP ? 

TOPG*0? 

XMPrPRnCESS [&LNULLPROC * JBDSEG3 ? 
lncr I-from 0 to 10 by 2 do 
begin 

PI^+jP 5 ^ 74 ^ 7 * IREADWRITE ACESS 

(.TMP+16+.T)a.T0RG? 

T0RG=.T0RG+128 
™ end? 

ItSET I/O PAGE% 

C .TMP+1 4)=#7?400? 1LF=127,ED=0 , ACF=7 

C.TMP+16+14)=#7600 
end? _ e 

%CLEAR REGISTER AND SET STACKfc 
begin 

local TMP? 

TMPsPROCESS [f&NULLPROC , JBGPR1 ? 
incr I from 0 to 12 by 2 do 
(,TMP+.T)=0 

t nd? 

OTHER INITIALIZATIONS <NAM£,PPN ETC> « 

end? 

while 1 do 
VAL*.VAL+1 

end 

eludom 


? 
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* j*”^i;,*|**:*”****«***********»*****»*»*****»»**.»**»*» 

I ®?°" R j ?t;Ug?h K. Panova. t 

* FUNCTION: This module implements tne process * 

I ™S e & l I e £iJ£f* clocic interrupt routine ♦ 

module EVENT ( NOT, 1ST I = „ ************************ 

% kernel process control functions 3 / 6/82 P.K.PANDYA* 


IREADY QUEUE NO, 

| WtlLli PROCESS NS. 

» SU d ER VT SOR STACK rj T 0 p LIMIT 
|CL ASS § EVENTS fcfALIM TO IfcBLIN 
• NO OF SEMAPHORES 0 TO SrfcSE*NO-i 
•EVENT NO FOR SEMAPHORE BLOCK 
iSTART OF SEMAPHORE QUEUES 


begin 

%EXTERNAL MACRO 

GfcRDYOUE 
&RNULLPROC 
&& 5 TKLIM 
MBMM 
&&SEMN 0 
&&SEMRLK 
S&SEMO 

require PARAM.BIU 
macro 

SEMQNOCARG)*APG+L«SEMQ$; 
jl ri 0 

MAPSR 0 =# 774 ? 00 ? i MAP enable register 
require PR 0 CQ 2 .R 1 H 

external TNITOUF , INSERT, FIRST, ISEMPTY; 1 FROM, QUEUE 

external L 0 Usrmap,setcomm,sftIup? . Mom memory 

external REAdclk,restclk,STRTCLK # 5 TOPCLKj 


CALCi lltu .UR f h* 9 DlKilu* # 5T l 

external CP, OLEpc.OLEPS. JIFFY, MPCSHJ 

own FLGCI.SSEMNO] ; fsEMAPHORE FLAGS 

routine savestate* 
beqin 

bind UREG1«#777762; MISER Ri 
local TMP; 

TMpsPROCESSr.Cp, JBGPRJ ; 
incr T from 0 to 12 by 2 do 

p«oi*8Kef;3»SSfS!toW 

PROCESS r. CP, JRPS1 a. OLFPS 

routine LOADSTATE ( PRQCNG ) * 
begin 

bind UREG1 *#*7777621 » USER Rl 


I FROM GLOBL.Bil 


1 SAVE USER REGISTERS Rl- 
i SAVE PC, PS 



word local tmpu 

TMPlsPRQCESSt.PROCNO.JBOPRJ ; 
incr I from 0 to 12 by 2 do 
r „ fUREGl+.I)».X.TMPl+.T)? 

LDllSR^AP ( •PROCNO) f 

it .PROCESS?. PR0eNQ,JBELG3<SUPBIT> tnen SET SUP( .PROCNO) 
end; 


LOAD USER GPRS 


global routine SCHEDULE* 
begin 

if ISEMPTYtifiRDYOUE) then 
CPattNULT-PROC 
else 

CP?FIRSTUtRDYOUE) ; {SELECT A PROCESS FOR RUNNING 


LOADSTATE(.CP) 


wwnww s. r\ ' \ # v. c s $ * w 

EROCESS C . CP 4 JRSTS1 aRUNSTS; 
i <START CLOCK> % 


CONVERT TO MACRO 


TRTCLKO? 

BORROW USER SEG 
FTCOMMC.CP); 


NT 0 FOR COMMUNICATION! 
ORROW COMMUNICATION SEGMENT 


beqin 

eu4 fAhac fTM C R JPC* * 

|apI§0*:mPCSR? toABLE MAP AS REQUIRED 
♦RSTKLTM* . PROCESS C, CP .UBPSl ,* 

CS^STKL I M «>2) = » PROCESS £«C D # JBPC1 1 
SP*$SSTKl IM-2; 
inline! "RTT**) IDISPATCH 
end 
end; 

global routine BLOCK(PRoeNQ)s 
begin 

SAVESTATEC); {'CONVERT TO MACRO 
PROCESS t .PROCfQ* JRSTSl =BLKSTS; 

% ACCOUNTING* * 

PROCESS f .PROCNQ , JBTIMEJ * . PROCESS E . PRQCNO, UBTIMEl +READCLK £ 5 ; STOPCLKC 

SCHEDULE O 
end; 

global routine AwAKE(PROCNQ)s 
begin 

{NAMED PROCESS TS PUT INTO *&PDYQIT£ 

PROCESS f .PROCNQ, JBSTS3 =RDYSTS; 

PROCESS! . PROCNO , 0BBLKI Dl=-1; 

INSERTCA^RDYQUg , .prochoi 
end; 
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global routine EWAIT (Procno #EVENTNO)s 
begin 

if .EVENTNO iss &SBLIM then 
oeQin 

PPOCESS£.PRhCWQ,JBBLKID5=.EVENTNO? 

BT,OCKC.PRnCNO) 

end 

end? 

global routine signL(PROCNO,EVENTNO)* 
begin 


if -EVERTNO lss &SBLIM then 

if .PROCESS £ . PROCNCl , JRSTSJ egl BLKSTS then 

If .PROCESS r . PROCNO , JB0LKIO1 egl .EVENTN0 then 
HTWIS JOB IS BLOCKED ON THTS EVENT 
AW»KE(,PROCNO) 

end? 

global routine INITSEM(NUMBER)s 
begin 

FLG E. NUMBER J=-l ?TNITOUECSEMQNO(. NUMBER)) 
end? 

global routine RESETSEMt NUMBER)* 

FLG NUMBER! *0? 

global routine wattsem(NUMBER)= 
begin 

if ,f LG (NUMBER! then 
FLG {NUMBER! sO 
else 
begin 

INSERTESEMONO (NUMBER) a .CP5? 

PROCESS t.CP, JBBLKIOlsI&SEMBLK? 

BI.OCK(.CP) 

end 

global" routine SIGNLSEMCNUMBER)* 
begin 

if ISEMPTY(SEM£)NO(. NUMBER)) then 
FLG r, NUMBER Js-t 
else 
begin 

byte local TMP? 

TMP=FIRSTCSEMONO(, NUMBER))? 

AWAKE(.TMP) 

end 


end; 
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global routine INTERRUPT CLOCKBLOCKn 
begin 

OLEPC* . OJjDPC s 
QL£PS«.OLDPS? 

PROCESS r. CP, JRSTS15RDYSTS? 

PROCESS C ,CP # JRTIME3 *. PROCESS UCP, JBTIME1 + .OIFFI ? 
if ,CP neq s&uuluproc then * 

begin 

INSERTCiSPDYQflE, .CP) mVESIATEC ) 
ena? 

SCHEDULE () 
end; 


global routine TNIT02s 
begin 

^INITIALISE MODULE EVENT% 
incr I from 0 to a*se m nd-i do 
INITSEM(.I); 

end? 


end 

eludom 
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bsste global ARRAY INpRUF£|&NOLINES,I6lHBSZ3 J 
bvte global ARRAY QUTRU c, ES&N0T,iNES,y&0rRSZ3 ? 
bvte global VFCTOP 
TNPFST: 

inplst; 

OUTFST! 

outlst: 

inpcounts 

OUTCO0NT USNOLINES) i 
external SI^NL; 

% TTY SCANNER MAINTAINS A CIRCULAR QUEUE FOR INPUT AND A CIRCULAR 

QUEUE FOR OUTPUT FOR EACH LINE, FOR EACH QUEUE TWO PIONTl 

Front and back- and a count of no. of elements is «atntai' 

EACH LINE HAS A STATUS WHICH SHOWS CONDITION OF LINE, 
i.e. ECHO, CTRL-C, FOLK ETC. I 

routine transmit* 
begin 

local tmp.tmidx? 

incr JX from 0 to NQLN1 do 

If .OUTCOUNT £ , JX3 <0 , 8> neq.o then 
If .STATUS £.JXKFREEBIT> then 
begin 

TMIDX*. OUTFST C , JXl <0 ,8> j 

TMp ®. OUTBUF C.JX».TMTDX3<0#8>; 

TMP^LINNO>=.JX<0,3>? 

TMRDs.TMp; . 

STATUS [ ,JX|<|FREEBIT>*Of 
OUTFSTC .JXKO , 8>= .OUIFST £ .0X3 <0 ,8>+l; 
if .OUTFST £.JX3 <0 #8> eql SfiOTRSZ then 
flUTFSTf ,JX3<0.8>*0| 

OUTCOUNT £ . JX3 <0 # 8>*. OUTCOUNT £.0X3 <0 , 8>«i ? 
if .OUTCOUNTE.JX3< r O,8> egl CWOTBSZ-1) then 

^IGNLC^fiTTTYf .JX) ,EVTiU 'OUT BUFFER NOT FULL 


end? 


routine INTERRUPT SCANNER* 
begin 

local lX.TMIOXj 
byte local ' T ’LTN»TCHJ 

IX* *1 ; 

%hile ,SYCS<BVAL> do 


begin 

IJts.IX+t; 

C«BUFf.lX3*.RDLS 


t 6 


end* 

incr I, from 0 to .IX do 
begin 

TtIN»,CHBUrr.I3<blNH0>? 
if *chbuf r . i j <rsts> then 

• A *?EW CHARACTER from some tty 1 

beain 

TCH»«CRBUF [ « 13 <0, 7>|, 

if i I !ilS8SS T f*I^Sl <0 '2 > eal ***NBSZ then, 

* <ERROR ACTT0M> % 

else > 
begin 

TM1DX*.1SPLSIC tTl»INl <0*8>? 

IMPBUFLTLlH..rMlOXU0.8>*.TCHj 

IMPOST [ . TTjIPj <0 .8> = . IWPIjSTI.TLINKO »8>tl ; 

if .If}PLSTC.fliIN3<0.8> egl &&TNRSZ then 


*» »AHrUUl L • K U « O c 

INPLST f ,f LTM1 <0 ,«>=0> 
J.WPCOONT C*TLIM] <*0 , 8>s« IN 


t&TNRSZ 

PCOUNTC . TfclHJ <0 « 8>+i i 


EVE^T <INPBITF EMPTX>NO»3FMFTY> 

f ,I*PC0HNTt.TLl*n<0 f 8> eel 1 then 

SlGNtj(£&TXTY( ,Tlt T N) ,FVTO) ; JTSP BUFFER NO| 
% STATUS CHANGE % 
if .TCH egl CTRLC then . 

STATUSC.TUNKCTl.CRIT^U 
if ,T£H eql EOLN then - », 

(STATUSt.TUNJ <bTNCNT>«. STATUS i.TbXlilkLXNCW 
if . STATUS UTLINJ«i,TNCNT> eel 1 then . 
SIGNi(tdrTY(.TUlN).EVT2) 3? 1 EOLN 


end 

end? 

if .CHBUFC.T3<TSTS> then 
ST6TFSC.^LTN3 <FREEBIT>»1 

AvvH « 

TRAMSFITO 

end; 

global routine OETCHCHNE# VARADDR) = 


liECHO CHARECTER % 

if . STATUS C.n, IN J<ECHOBIf> then 

if .OUTCOUMTC,TLIN1<0,R> eoi SCQTBSZ then 
% <CANT ECHO THE CHARFCTER > f 
else . 
begin 

TMIDX*. QUTLST t -TLIN] <0» SV* 
OUTBUFl.TUIN, „TMIDX3 jfQj>8>*«TCHf - „ 

OUTLSTC.TLINl<0,B>s.nUTLSTi.TLiNfc^O,8| 
if ,0UTjuSTr.TliTNl<0,8> eol C^QTBSZ the 
OUTTjSTE .TUINJ <0 » 8>=0 ! . 

OUTCOUMTC.TLTN]<0,8>a.OUTCDUKT#.TLINl^ 

end 
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begin 

local tmidx? 

TMIDX* . TNPFST f .LINE! <0,8 » ? 

( . VARADPRKO, 8>s.TNPBUF C .LINE, . TMIDX] <0,8>? 

If .INPRUF£.LTNE,.TMIDXl<0,8> eg! £f)LN then 

Status e .line] «lincnt>=. status e .line] <ltncnt>-i ? 

IHPFSTC,LINE3<0,8>=.INPFST[*LT»E]<0.8>+1 ? 
if. . XNpFS' r C.LTNE3<0,8> eql *&IN8SZ £nen 
INPFSTT .LINE] <0,8>=Q? 

INPCUUNT E .LTNE] <0 , 8>=.INPCQUNT£ .LINE] <0,8>-l ? 
return 
end? 

global routine PUTCH(LINE,CHAR}= 
begin 

local TMIDX? „ . 

TMIDX*. OUTLSTC. LINE] <0 ,8>f 
OUTBUF [ .LINE, .TMIDX] <O,R>=.CHAR<0,8>? 
OUTLST£.LINE]<0,8>*.OUTLSTULINE3<0,8>+1? 
if .OUTLST C.LTNEJ<Q»8> eql S&OTMSZ then 
OUTLSTI .LINE] <0 ,8>*0? 

OUTCOUNTC.LINFj< l O,8>-.OUTCOUNT£.LlNE3<0,8>+i? 

TRANSMITO; 

return LRETURN WITH SUCCESS 

end? 

global routine FLUSTN(LINE)* 
begin 


! REM «0,8§ 


INPFST £,LINEJ^0 i 8>*INPLST C .LINE] <0 ,8>*INPCQUNT £ .LINE] <0 , 8>=0? 
STATUS 1*1 ‘ 


„ jLINE3<CtLC3IT>*0? 
STATUS £ .LINE] <LINCNT>*0 


end? 

global routine FLUSOUT CLINE)* 
begin 

%LOCAL TEM? 

IF .OUTCOUNTC .LINE] <0, 8> EQL i&OTBSZ THEN TE 
OUTFST £ . LINE! <0 , 8>=0UTLST £ . LINE) <0 , 8 >«OT?TCOUNT C . LINE] <0,8>=0? 
STATUS £. LTNF) <FREFBIT>*i? 

%IF ,T£M NEO 0 THEN 

SIGNLCi;&irm.HNE),EVTl)i 

end? 

global routine ECHQ(LINE)* 

STATUS r, LINE! <FCH0RIT>=1 ? 

global routine NOECW0CLTNE)* 

STATUS r . LINE] <ECH0RIT>=0 ? 

global routine RESET (LINE)* 
begin 


%LOCMi TEM? 


end 

eludom 


fpM- 

KprnDi#V I ffir?rf > ;i N SfiI! r -^i«ll<o. 

If Iffllf "* Wf 5K?*I wST? 0UI 91 c • 

8r™?fe L i;gS , S E S8?S IT> ’ 1 ’ 

end; siGNLCff&irTj 

glob ^npt%mhr< jpi«PF^we5* 

. INPCOUNT £ <0 , 8> eql 0? 

Ql0 ?84»S8H*K t ?gfr?fcJK*5ST *™, 

,lo ttMmN6Jm8 ,e & „ 

S^Obal routine TNIT05= 

D 60 ift 

CHVT?=SCANNEP; 

CCHVT+2) =*2401 tPRIO-5 , E=0 , RaO , SUPS 

1 c Uetc°i>? to ’ ,0I ' N1 1,0 

TMffCs&B??* 

end? YCS<BRE ^ =SYCS<TMEW>=SYcs<BFBN>s;1 
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% ********************************************************* 

* MODULE ! SYSCAL 

* AUTHOIJR ; Pari tosh K. Pandya. 

* DATE ; 24/7/82 

* function: This module handles user's service 

*********** ******?*!!*!$:**** ************** ****** ********** 

module syscall umhisv)* 
begin 
bind 

TRPVC*fiO, 

ARGls#777774, 

APG2=#77777? 

ARG3=#777770, 

APG4=f777766; 

%EXTE R NAti MACHO 

jfcfcCOMM(ADDR) i ACCESS COMMUNICATION . 

S&TTY OGIVES TTYNO FOR GIVEN PROCESS* 

require param.bji? 
require DEFFIL.B11? 
require PRQCG2.B11?. 

external CR,OLEPC,OLEPS? 1 FROM GLOBFL.Bll 

external BLOCK , AWAKE , FWAIT,SIGNL , WATTSE* , S1GNLSEM, SCHEDULE? 
%XTY SUBSYSTEMe _ 

external Getch , putch , futsin , flusout. echo , noechg , reset; 
external inempty,outful,linein,intto5? 

^MEMORY SUBSYSTEM* 

external SETUSR , SETPRI V,SCAN ,SETSUP, LDUSRMAP? 
external SUPSErvige? 

routine interrupt monitr* 
beain- 

switches UNSAFE? 

olepc».oldpc?olepsr.oldps? 

select . ARG1«0,P> of 
nset 

STtv subsystem calls 
TRPO; 

I RESET LINE 
beq 1 n 

RESET (fc&TTY(. CP))? 

ARG1*Q? 

end? 

TRPi ; 

ilNEMPTY 

begin 


***** 
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“ ISff5J*|gp«*w» tr > en 
f^f<8^giS°' 3>=0 '- 

end? 

TPP2? 

IGETCH 

begin 

lf 5e||n T)fC&Sm(,CP)) then 

oEErc=.o[Ipc-2) STR " CTInN “«■»«» 
rmnlcP'Fhtl 

end 

else 

begin 

local imp? 

^!§ssr- cp, ' rHp ” 

ARGl = « T MP ? 

^ end 
end? 

TRP3? 
iSET ECHO 
begin 

FCHO(&STTY(.CP))? 

ARG1=0 

end; 

W4* 

1SET MOECHO 
beain 

NOFCHOC&&TTYC.CP))? 

ARGlssO 

end? 

TRPSi 

JPUTCH 

begin 

if mpwWYi.CPn tnen 
begin 

nLEPC=.OLEPC-2? 

PwilTC. QP, EVT1) 
end 
else _ 
begin 

local TMP2? 
m « n 2=.ARGl<8,8>? 

puXCH(s$ttyc,cp5 # .tmp2>; 

ARC i s0 ? ** * 

end 


end? 
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TRP6S 

•miSTN 

begin 

FLUSINC&ATm.CP))? 

ARGl=G 

end? 

[Run class monitor calls 
W50: 

[SWITCHSUP 

SETSHPOl *<L0AD SUPERVISOR MAP>$ 
PROCFSS £ . C P , StJPPC 3 * . OLEPC ? 

PROCESS [.CP, SUPPS ] a . OLEPS ? 

PROCESS C .CP , JBFLC3 <SUPBIT>*i ? 
KTQAD SUPERVISOR ENTRY PQTNT>% 
OIjOPCsSUPSERVICE ? 

OLDPS=#1400? 

end; 

TPP5U 

‘RESTORE USR 
begin 

LDUSRMAPO; %<RESTORE USR MAP>% 
OLDpCs. PROCESS t .CP,SUPPC1 ? 
OLDPSs«P D OCESSf.CP,SUPPSJ ? 

PPOCFSS t .CP , JBFLOJ <SUP c 'IT>aO; 
end; 

TPP55! 

IRuo(addr) 

beqin 

if . ARG2 Iss #17770 tnen 
beqin 

local tmp # 

TM^aSCANC liCOMH C . ARG2 5 7 ? 
if .tmp qeq 0 tnen 
beqin 

[VALID CALL 
SETUSRf. CP, 

AW AKEC.CP)? 

SCHEDULE () 

end 

, end? 

*&C0MMC0)=U 
&&CQ M Mf 27=1? 

SETUSRC .CP, 05 J 
AWAKFC.CP); 

SCHEDULEO 
end? 

TRP56S 

[RUN A USERS LOADED PROGRAM 
begin 

local TMP1? 


,TMP) ? 


[ERROR IN CHAINING 
‘GOTO COMMAND PROCESSOR 
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I8&&»55°SSSS| S Cf,J8D k EN! ? 

ARG2,.T*P! ,.ARG3)y 


. end 
eludom 


vSETPRlVC.CP, 
S&CO w Hf 0 ?= 0 ; 
AWAKE(.CP)? 

schedule f ) 

end? 

TRP‘ 57 : 

£egfn FR0M A 

§§SR!W> s0 '* 

f§TUSR(.CP f 0 )? 
AviAKE(„CP}? 
SCHEDULE O 
end? 

. tesn 
end; 

gl0 K*L£ 0Utine Tfiifoe® 
begin 

TRPVC=HnNITR? 
CTRPvrf?)=#» 340 ; 
end; 


i command processor 


iSUP MQDE#GPR 0,PRIO 7 
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% ************* ********************* #**#***#***###* ******** 

* MODULE ; BOOT * 

* ! StU^S5 h K * p andva. * 

* DME : 24/7/B? * 

* FUNCTION: This module boots the operating system * 


module BOOT (MiUNC t50)i = 
begin 

external 
EXTRSNAL 
external 
external 




„ . .TNIT08! 
INSERT . SCHEDULE , SETUSRJ 
I.DKERNAP? 


require PARAM.Bin 
require PRQCQ2.R11J 


TNI701C);INTT02 0!INIT03C)JINIT040|INIT050! 

INIT06O jINIT07f >!IN itqrO; { Tnitalise all system module 

lActive proaram table must be set here. alsoUser work: areas 
„ „ _ „ _ are assigned here.* 

PROCESS Cl , JBDORG] «#,t 200 i 
PROCESS?!, JBDT EN3=#20O? 

PROCESS C2 , JBDORG3 *# » 400 J 
PROCESS ?2#JRDT>ENJ =#200? 


^Initialise the .process descriptors to run the comd 
processor. ~ 

SETUSRl 1 , 0) J SETUSRC?#0) y 


%Insert the processes in ready emem 
INSERTf «fS;RDYQtIE, 1 1 ? INSERT f &&RDY0UE, ! 


% 

♦ 

# 


LDKERNAPO; 

%Dispatch the first lob % 
SCHEDULE C 5 


end 

eludorr 
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% ********************************************************* 

* MODULE ; SUPERVISOR 

* autfqur i Pari tosh K. Pandva. 

* DATE j 24/7/82 

* FUNCTION! This module implements the supervisor 

* mode. The fileing system runs in this 

* mo^e. 

*********************************************************1 

module. supervisor* 
begin 

it FILE SYSTEM PRIVATE DATA DEFINITION! 
global routine SUPSERVICE C FN , 4RG1 , ARG2 , ARG3 , ARG4I* 
begin 

case ,FN of 

cgf 

IFILE SYSTEM ROUTINES COME HERE! 
tes 

end? 

global routine INITIO* 
begin 

%FILE SYSTEM INITIALISATION! 
end ; 

end 

eludom 


f 
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% ******* ************** ****************** ****************** 

* MODULE S USRMAC 

* AtJfHQUR s Pari tosh K. Pandya. 

* DATE : 24/7/8? 

* FUNCTIONS This module provides the macro 

* definitions used bv user programs to 

********************************** 1 **********************^ 

%USR MACROS! 
require DEFFIL.Bii; 
macro 

&TTRST* 
begi n 

register ,VAl=1? 

VALsO? IRESET &TTOINE 

TRAPCO) 
e nd$ f 
&TTINEMT* 
oegin 

register VAL*1? 

VALsl; 

TRAPCO ) I 

If ,VAL<0,8> then return -1 
else return 0 

&ttI|;tch(addr)3 

oegin 

register VAL=1? 
val*2? 

TRAP (0) ; 

ADDR*,VAt»«0,8> 
end$ , 

&TTPUTCHCCHAR)* 

begin 

register val=1? 

VAL<8,R>=CHAP; 

VAL<0 , 8>“5 * 

TRAPCO) 
enaS , 

&TTECH0= 

oeqln 

register VAi,»tj 
VAL5TRP3J 
TRAPCO) 
ends , 

&TfNOECHO= 

begin 

register vai,= 1 ? 

VAL=TRP4; 

TRAPCO) 


*-***** 



ends , 

STTFIjUSIN# 

oegin 

VAI»“»TRP6 * 

TRAPCQD 

ends, 

montor calls 

&RUH ( ADDED* 
begin 

register VAL1*U 
register VAL2=7? 

YAT.1*TRP55? 

VAL2=ADQR; 

TRAPC0) 

ends , 

&RUNPRIV( LEW# ENTRY)* 

oegin 

register VALi=1 ; 
register VA b?.*2t 
register val3*3; 
VAL1=TRP56? 

VAL2=LEN ; 

VAL3*ENTRY; 

TRAPfO) 

ends , 

5.EXIT* 

oegln 

register VAL*1 j 

VAL*TRP57» 

TRAPCO) 

ends; 



$ p ~ - PAM-T) W 



